基于金融场景的数据库性能评估工具

1　引言

随着移动终端的普及和电子商务时代的到来，如今移动支付已经成为新时代用户的一大特征。这一趋势带来了大量的用户、丰富的场景和海量的数据，对数据库的性能提出了新的要求。据统计，淘宝的“双十一”营业额在9年内增加了将近4000倍，即从2009年的5200万元增加到2018年的1934亿元。

近年来，越来越多的厂商将目光投向了金融领域，推出了自己的事务数据库。与此同时，各大银行为了满足日益增长的交易需求，也在不断对现有系统进行优化升级，同时对数据库这一核心部件进行选型升级。在市场需求和行业动力的双重驱动下，如何对数据库软件进行选型、如何衡量金融业场景下数据库产品的性能成为一大突出问题。目前，金融场景事务数据库选型还存在诸多问题：银行不能直接将真实系统开放给厂商进行调试，两者间缺乏缓冲区；行业内没有一套标准的测试工具和测试流程，测试结果难以进行比较；厂商往往使用商品批发模型进行性能测试，不能完全模拟真实金融业务中产生的压力。

为了解决上述问题，本文首先研究了当前数据库产业性能测试的现状，对现有的基准和工具进行了比较和分析；随后针对上述问题和产业现状开发了一款基于金融场景的事务数据库性能测试工具，涵盖了数据库性能、ACID性质等一系列指标；最后，对事务数据库性能测试提出了建议。

2　TPC-C测试基准和工具

2.1　TPC-C测试基准介绍

TPC-C是由事务处理性能委员会（Transaction Processing Performance Council，TPC）在1992年发布的针对联机事务处理（OLTP）数据库性能的测试基准，是一种只读和更新密集型事务的混合，用于模拟数据库在复杂OLTP环境下的性能。TPC-C采用混合负载，数据库由不同大小、性质和关系的表组成，测试时有多个终端并行模拟，通过数据的访问、更改和征用衡量数据库的性能。

2.2　TPC-C模型

TPC-C模型模拟了仓储物流场景（见图1），假设某家公司有n个仓库，每个仓库为10个地区供货，每个地区平均有3000名顾客，平均每个顾客的一个订单中有10种不同的商品，且所有订单的商品中要求有1%来自别的地区的仓库进行供货。

图1　TPC-C 仓储物流场景图

TPC-C的仓储物流模型对现实中的场景进行了抽象和简化，抽象后的场景共由9张表组成，之间的关系见图2。

图2　TPC-C 模型各个表的关系

通过图2可以看到各个表之间的数量映射关系，值得注意的是，TPC-C基准使用仓库数w作为调节初始数据量大小的基本单位，仓库的数量决定了被测系统的负载，从而进一步影响最终的结果。

针对以上场景，TPC-C设计了5种不同的业务，分别是新订单事务、付款事务、订单查询业务、库存检查事务和递送事务。测试过程中就是不断执行这5种业务的混合负载，最终使用平均每分钟完成的业务数量，即tpmC来衡量数据库的性能。

2.3　TPC-C模型的问题

然而，应用在金融行业，TPC-C模型却由于其先天设计，而存在一些难以解决的问题。

（1）TPC-C模拟的仓储物流模型和金融业实际生产中的转账、查询、代发工资等业务场景相差甚远，并不能很好地模拟金融行业实际生产中出现的诸如热点网点、热点账号造成的锁阻塞现象。同时，不同规模的银行的数据规模差距较大，如果仅通过仓库数量w对测试负载进行调控很难真实且准确地模拟选型银行自身的业务量，造成测试结果和真实性能的“误差”。

（2）TPC-C官方并未提供任何测试工具，厂商往往依赖于开源第三方或者自己编写的测试工具进行测试，这就造成了测试工具五花八门，很多测试工具自身就存在bug，直接影响了测试结果的可信度。更重要的是，厂商可以通过对工具代码进行更改或是将热点数据存放在内存中直接影响最终测试得出的tpmC值，而这无疑不能反映真实场景中的性能。

（3）TPC-C对测试使用的硬件环境不作要求，这使得TPC-C的测试结果往往难以直接反应出数据库软件的性能而更多是软硬件解决方案的综合性能。因此，研究TPC-C榜单可以发现，往往是Dell、IBM等硬件厂商出现在榜单上。在当前TPC-C榜单上仍有效的9个成绩中，有8条都是Goldilocks v3. 1 StandardEdition在不同硬件平台上的测试成绩。这说明TPCC基准的测试模式并不能有效地体现出数据库软件的性能，这也造成了其结果难以进行横向比较。

3　金融场景模型

3.1　金融场景模型设计

本项目的模型抽象来自真实银行业核心系统（见图3）。假设一个银行有n个网点，每个网点有m个科目，所有网点共有x个用户和y个账号。同时，银行需要给n/4数量的员工进行代发工资。在业务运行过程中，所有的交易记录都需要记录在日志表中，而所有产生资金流动的交易都需要记录在流水表中。此外，账户表中还设置了10%的无效或冻结账户，用于模拟真实业务。

图3　金融场景模型图

通过对真实银行核心系统的抽象和简化，同时考虑到ACID检测的实现，抽象后的场景由被测数据库和本地数据库共17张表组成（见表1、表2）。被测库主要存储测试运行的相关数据，而本地库则主要保存参数和集群配置。

表1　本地库表结构

表2　被测数据库表结构

其中，业务执行过程中主要涉及的表有branch、sjno、account、customer、salarylist、tranlist和tranlog。而chkuplog则是用于在程序运行过程中实时记录ACID性质的检测结果。本场景通过网点数n、科目数m、用户数x和账户数y共同调节初始数据规模，并可根据不同银行的规模来调整工具产生的压力值。

3.2　金融场景业务设计

选取6个具有代表性的金融业务，分别是转账、存款、取款、账户查询、代发工资和资产盘点。在业务的事务设计上，基于真实核心系统的设计规则，将每个大的业务分为3个事务完成。

（1）根据随机选取的账号，确定账号所属的网点，并对网点内这一行数据加锁，网点流水号加1，提交业务，释放行锁。

（2）对选取的账号状态、余额等进行校验，如果校验成功，运行业务逻辑。如果业务逻辑涉及交易，那么在tranlist流水表中记录两条相应的记录（特别的，所有涉及金额交易的业务在插入交易日志tranlog时均会插入两条记录用于区别借贷双方）。

（3）在业务交易完成后，在tranlog表中插入一条记录，记录交易日志。

由于行业的特殊性，整个业务流程中不会涉及数据库的删除操作，所有的业务均是由查询、插入和更新组成的混合负载（见表3）。其中，资产盘点由于遍历全表的特性，只在所有其他业务结束后单独运行一次，用于模拟金融核心系统的跑批功能。其他5种业务组成混合负载对数据库性能进行测试。

表3　金融场景的6种业务负载

选定了业务运行时间、每个业务运行时间、每个业务运行平均时间、90%响应时间、TPS（每秒钟完成的业务数量）、业务运行时间方差作为衡量数据库性能的指标。

4　金融场景测试工具的实现

4.1　数据初始化流程

基于上文所定义的金融行业场景，工具的初始化流程主要分为3步。

（1）读取被测库中datacfg表中的数据，确定初始化数据的规模，随后读取本地库paramcfg表中的参数，确定工具运行过程中的设置。

（2）根据参数初始化网点表，再根据网点数和科目数初始化科目表，最后初始化用户表。

（3）初始化账户表，为每个账户随机的分配网点、科目和账户，最后生成代发工资表，为代发工资列表分配账户。

4.2　数据运行流程

在输入测试开始的指令后，工具首先会从trancfg表中读取本次测试使用的测试规模；随后开始测试前一致性测试，测试结束后根据测试规模开启相应数量的线程执行相应的业务，业务执行过程中所有业务交易都会被记录在交易日志表中用于持久性测试和指标统计。当所有线程均达到设定运行次数，线程关闭后，程序会开始测试结束后的一致性测试，再进行资产盘点业务的执行。当资产盘点业务运行完毕后，工具会开始各项指标的统计并输出到屏幕上。

工具还会将业务运行过程中所有的消息和错误分别输出到/logs目录下的文件中，方便测试人员对出现的问题进行定位和debug，或是对数据库运行情况进行记录和分析。

4.3　ACID性质检测

ACID性质的自动化检测是工具实现中的一大重点。其中，原子性和隔离性需要在业务运行过程中不间断地进行检验，持久性需要将被测库的数据与本地库中的交易日志数量进行对比，而一致性则需要业务运行前后各运行一次，通过多个指标来进行检测。

在数据初始化时，工具会预先初始化用于原子性检测和隔离性检测的一系列账号。在业务运行中，程序会自动开启一个线程，通过对数据库进行提交或回滚作业检测数据库的原子性。同样的，对于隔离性，工具会开启两个线程，通过两个线程对同一个隔离型账户进行操作来检测数据库的隔离性。

在被测数据库插入交易日志成功后，程序会开启一个异步线程向本地库插入同样的多条。在业务运行结束后，程序会检测本地库和被测库的交易日志数量是否相等，以此验证数据库的隔离性。

持久性测试会运行两次，在业务运行前执行主要的目的是记录当前系统内所有账户金额的总和。随后在业务执行完毕后再执行一次，数据库应当满足以下关系。

（1）测试结束后账户金额总数=测试前账户金额总数+存款造成的差额。

（2）流水表中借贷双方总额应当一致。

（3）网点流水号=日志表中对应网点日志数量+1。

（4）转账业务（存款、取款、转账）的交易日志数量是交易流水数量的两倍。

（5）代发工资业务的交易日志数量和交易流水数量相等。

ACID性质检测中的另一大重点是，如何处理关机、断节点等情况出现的异常。工具通过对所有的事务都添加了完善的异常处理，并且对异常处理失败、回滚还失败的情况也做了处理，同时对插入交易日志部分添加了重试机制，确保功能能够捕捉到所有因为高可用测试出现的异常，保证测试结果可靠。

4.4　工具兼容性

工具性质决定了工具必须能够兼容多种不同架构的数据库，才能展开对不同数据库的性能测试工作。因此，如何对工具和数据库进行适配也是工具实现过程中的一大重点。鉴于不同数据库的语句往往存在非常巨大的区别，如果将sql语句编译在工具内部，那么在适配过程中，对语句进行调试时不可避免地会不断进行编译，增加适配的工作量和复杂度。因此，工具采用了MyBatis框架，将DML语句直接暴露在数个XML文件中。数据库厂商可以直接通过改写XML中的sql语句即可完成适配。

5　结束语

本文分析了产业界金融领域事务数据库测试的现状和问题，在此基础上提出了金融领域事务数据库测试场景的定义和业务设计，并基于此金融场景，实现了一款金融领域数据库测试工具。该工具能够模拟真实业务场景，从多个维度对数据库性能进行测试，对未来事务数据库领域的发展和开拓具有非常重要的意义。未来，还将进一步完善该场景和工具，增加更多的业务场景，改进工具使用中出现的问题，完善相关的文档，使其能从全面性、易用性和可靠性上更好地为金融领域事务数据库的测评和选型提供数据。

参考文献

[1] 刘雷, 郭志军, 马海欣, 等. 分布式数据库在金融应用场景中的探索与实践[J]. 大数据, 2019,5(1):77-86.

[2] 马鹏玮, 魏凯, 姜春宇, 等. 分布式事务数据库系统评估体系[J]. 信息通信技术与政策, 2019(5):14-18.

[3] 孙雪祥, 蒋艳凰, 张怡. TPC-C测试系统的实现[J].计算机工程, 2006(20):81-83.

[4] 李梁, 吴刚, 刘辉林, 等. 数据库性能测试可视化工具VisualDBBench及面向内存数据库的应用[J]. 华东师范大学学报(自然科学版), 2014(5):340-350.

[5] TPC. Transaction processing performance council[EB/OL]. (2014-06-30)[2020-01-20]. http://www.tpc.org.

[6] 王良, 蔡荣. 基于TPC-C标准的自动化测试工具TPCCLoader[J]. 计算机工程与应用, 2006, 41(25):102-105.

[7] Database benchmark[EB/OL]. (2014-07-02)[2020-01-20]. http://database-benchmark. com/.

[8] BenchmarkSQL[EB/OL]. (2014-07-02)[2020-01-20]. http://benchmarksql.sourceforge.net/.

[9] TPC BENCHMARKC Standard Specification[EB/OL].(2009-02-11)[2020-01-20]. http://www.tpc.org/tpcc/spec/tpcc_current.pdf.

[10] 司冠南, 许静. 基于TPC-C的XML数据库测试方案[J]. 计算机工程, 2010,36(19):37-38+41.

[11] 高艺, 赵成, 张毓森. 基于TPC-C基准的ACID验证工具的实现[J]. 军事通信技术, 2008,29(2):90-93.

[12] 武海平, 余宏亮, 郑纬民. 通用海量数据库性能测试系统的设计与实现[J]. 清华大学学报(自然科学版), 2006(7):1309-1312.

[13] 姚竞英. 数据库性能测试的研究[J]. 电脑知识与技术, 2011,7(29):7090-7092.

作者简介

田稼丰：中国信息通信研究院云计算与大数据研究所大数据与区块链部工程师，研究方向为大数据、数据治理等。

姜春宇：中国信息通信研究院云计算与大数据研究所大数据与区块链部副主任，高级工程师，研究方向为大数据、区块链等。

本文刊于《信息通信技术与政策》2020年第4期

主办：中国信息通信研究院

《信息通信技术与政策》是工业和信息化部主管、中国信息通信研究院主办的专业学术期刊。本刊定位于“信息通信技术前沿的风向标，信息社会政策探究的思想库”，聚焦信息通信领域技术趋势、公共政策、 国家/产业/企业战略，发布前沿研究成果、焦点问题分析、热点政策解读等，推动5G、工业互联网、数字经济、人工智能、区块链、大数据、云计算等技术产业的创新与发展，引导国家技术战略选择与产业政策制定，搭建产、学、研、用 的高端学术交流平台。

校  审 | 陈  力、珊  珊

编  辑 | 凌  霄

”

推荐阅读

新型电信智能卡安全分析及发展建议
《新基建》专辑

点亮在看共渡难关